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PREFACE 


The  Executive  Summary  is  the  first  volume  in  a  three-volume  Final  Program  Report.  It 
contains  a  summary  of  the  objectives,  methodology,  results,  conclusions,  and  recommendations 
of  the  Integrated  Maintenance  Information  System  (IMIS)  program.  The  overall  scope  of  the 
IMIS  program  was  to  (I)  identify  and  define  the  requirements  for  IMIS;  (2)  develop 
specifications  documenting  the  requirements;  (3)  design  and  develop  a  demonstration  system 
capable  of  supporting  the  essential  IMIS  requirements;  (4)  evaluate  the  IMIS  concept  and 
requirements  using  the  demonstration  system;  and  (5)  finalize  the  IMIS  specifications  by 
incorporating  the  results  of  the  tests,  demonstrations,  and  evaluations.  The  program  was 
structured  to  satisfy  the  scope  by  applying  information  gained  during  each  phase  to  the 
subsequent  phases. 

The  IMIS  Field  Test  and  Demonstration  was  separated  into  three  parts:  Debrief  Test,  End- 
to-End  Demonstration,  and  Fault  Isolation  Test.  The  primary  objectives  of  these  activities  were 
to  (1)  test  the  IMIS  concept  under  realistic  operational  conditions,  where  possible,  (2)  evaluate 
the  effectiveness  of  IMIS  in  supporting  the  maintenance  mission  of  the  unit,  (3)  demonstrate  the 
technical  advantages  of  IMIS  over  the  current  system,  and  (4)  identify  strengths  and  weaknesses 
of  the  demonstration  system  which  could  be  used  in  defining  requirements  for  a  production 
implementation. 
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INTEGRATED  MAINTENANCE  INFORMATION  SYSTEM  (IMIS) 

EXECUTIVE  SUMMARY 


INTRODUCTION 

The  Air  Force  has  developed  and  is  continuing  to  develop  several  computer  systems  to 
support  organizational-level  (0-Level)  maintenance.  Unless  planned  integration  occurs,  the  Air 
Force  of  the  future  will  have  multiple  computer  systems  in  use  simultaneously,  causing 
confusion  as  a  result  of  incompatible  hardware,  data  requirements,  user  interfaces,  and  expertise 
required  to  operate  and  maintain  the  systems.  These  deficiencies  can  cause  improper  weapon 
system  maintenance,  potentially  leading  to  weapon  system  malfunctions,  equipment  damage  or 
loss,  or  even  personnel  injury.  This  degradation  in  weapon  system  and  unit  readiness  limits  the 
ability  of  combat  organizations  to  accomplish  their  assigned  missions. 

The  Integrated  Maintenance  Information  System  (IMIS)  is  a  proof  of  concept  program  to 
integrate  all  maintenance  information.  It  is  the  tool  to  access,  from  all  available  sources, 
information  required  to  support  maintenance  and  then  integrate,  format,  and  present  that  data  for 
use  by  maintenance  personnel.  By  integrating  the  information  from  the  maintenance  support 
systems  currently  in  use  and  providing  a  standard  mechanism  for  accessing  and  presenting  that 
information,  IMIS  can  eliminate  the  need  for  maintenance  personnel  to  learn  the  unique 
operations  of  and  interact  with  multiple  systems. 

Since  1976,  the  Armstrong  Laboratory  Logistics  Research  Division  (AL/HRG)  has 
conducted  several  research  and  development  (R&D)  projects  to  develop  the  technology  for  the 
presentation  of  technical  data  on  an  automated  system.  From  1976  through  1988,  these  efforts 
included  two  feasibility  studies,  the  development  of  two  prototype  systems  to  support 
intermediate-level  (I-Level)  maintenance,  and  the  development  of  a  portable  computer  system  for 
presentation  of  technical  data  for  on-equipment  maintenance.  The  scope  of  these  efforts 
involved  performing  laboratory  studies  to  develop  the  required  technologies  and  testing  the 
prototype  systems  under  realistic  field  conditions  to  ensure  the  systems  satisfactorily  met  the 
needs  of  the  users. 

AL/HRG’ s  R&D  efforts  demonstrated  that  the  presentation  of  maintenance  technical  data 
on  a  computer-based  system  was  feasible  and  that  an  automated  system  had  the  potential  to 
improve  performance  and  reduce  the  costs  of  maintaining  the  Air  Force  technical  order  (TO) 
system.  Furthermore,  effective  user  interface  techniques,  data  presentation  techniques,  and  draft 
specifications  for  computer  hardware  and  software  were  developed. 

In  addition  to  demonstrating  the  benefits  of  an  automated  data  presentation  system,  these 
studies  also  indicated  the  need  for  a  more  comprehensive  system,  in  which  the  maintenance 
information  available  to  all  Air  Force  maintenance  personnel  not  just  the  technician,  could  be 
improved.  The  lessons  learned  from  these  efforts  played  a  major  role  in  developing  the 
Operational  Concept  Document  (OCD)  which  formed  the  basis  of  the  IMIS  program. 
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The  overall  scope  of  the  IMIS  program  involved  several  different  thrusts:  to  identify  and 
define  the  requirements  for  IMIS;  to  develop  specifications  which  document  those  requirements; 
to  design  and  develop  a  demonstration  system  capable  of  supporting  the  essential  IMIS 
requirements;  to  evaluate  the  IMIS  concept  and  requirements  using  the  demonstration  system; 
and  to  finalize  the  IMIS  specifications,  incorporating  the  results  of  the  tests,  demonstrations,  and 
evaluations  conducted.  The  structure  of  the  program  was  intended  to  satisfy  each  of  these  major 
thrusts  to  allow  maximum  application  of  information  gained  during  each  phase  to  the  subsequent 
phases. 

This  Executive  Summary,  the  first-volume  in  a  three-volume  Final  Program  Report, 
contains  a  high-level  summary  of  the  objectives,  methodology,  results,  conclusions,  and 
recommendations  of  this  program  (contract  #F33615-88-C-0024). 


OBJECTIVES 

The  primary  objective  of  IMIS  is  to  improve  the  performance  of  aircraft  maintenance 
organizations  by  providing  Air  Force  personnel  an  effective  maintenance  information  system. 
The  improved  information  system  would  increase  the  performance  capabilities  of  the 
maintenance  personnel,  resulting  in  an  increased  sortie  generation  capability.  Specific  objectives 
for  IMIS,  as  identified  in  the  OCD,  are  listed  below. 

a.  Integrate  multiple  maintenance  information  sources  into  a  single  easy-to-use  information 
system. 

b.  Tailor  information  to  meet  the  specific  needs  of  the  task  and  the  technician. 

c.  Provide  an  on-the-job  training  aid  for  new  systems  and  proficiency  training  on  existing 
systems. 

d.  Eliminate  time-consuming  paperwork  and  tasks  through  automation. 

e.  Improve  on-aircraft  diagnostics  and  reduce  “Can  Not  Duplicates”  (CNDs)  and  “Retest 
OKs”  (RTOKs). 

f  Improve  the  quality  of  maintenance  performance  by  taking  advantage  of  the  computer’s 
ability  to  interact  with  the  technician. 

g.  Maximize  the  utilization  of  available  manpower  resources  by  providing  information  in 
standard,  generic  formats  independent  of  the  subsystem  and  supporting  general  technical 
capabilities  at  various  skill  levels. 

h.  Improve  the  maintenance  capability  for  dispersed  operations  by  packaging  the  needed 
maintenance  information  into  a  highly  portable,  deployable  system. 
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i.  Provide  the  capability  to  support  maintenance  performance  in  future  scenarios  of 
consolidated  specialties. 

Although  many  of  these  objectives  focus  on  the  maintenance  technician,  the  goal  of  IMIS 
is  to  improve  performance  of  all  maintenance  personnel,  regardless  of  their  role  in  the 
maintenance  process.  By  allowing  easy  access  to  current  maintenance  information,  IMIS  would 
enable  all  maintenance  personnel,  including  technicians,  managers,  and  support  personnel,  to 
make  more  informed  decisions,  thereby  improving  the  maintenance  process  and  increasing  the 
availability  and  mission  readiness  of  the  weapon  systems. 


APPROACH 

This  program  was  conducted  in  three  phases:  Requirements  Analysis,  System  Design  and 
Development,  and  Demonstration  System  Fabrication  and  Field  Evaluation.  Figure  1  shows  a 
high-level  schedule  for  each  phase,  including  significant  milestones.  Figure  2  shows  the  key 
IMIS  activities  and  the  products  of  those  activities  in  the  three  phases.  The  following 
subsections  discuss  the  tasks  performed  in  each  phase. 

Phase  I:  Requirements  Analysis 

The  main  objectives  of  the  Requirements  Analysis  phase  were  to  identify  and  analyze  the 
functional,  informational,  and  human-computer  interface  requirements  for  an  IMIS  in  the  Air 
Force  maintenance  environment;  develop  a  system  architecture  which  supported  those 
requirements;  and  develop  system  functional  requirements  specifications.  A  critical  task  in 
support  of  the  requirements  analysis  was  interviewing  maintenance  personnel  at  several  Air 
Force  bases.  The  primary  products  of  Phase  I  were  the  IMIS  Architecture  (IMISA),  developed 
using  a  structured  analysis  methodology,  and  the  System/Segment  Specification  (SSS),  which 
documented  the  IMIS  system  requirements.  This  information  was  reviewed  at  the  System 
Requirements  Review,  conducted  at  the  end  of  Phase  I. 

Phase  II:  System  Design  and  Development 

After  the  desired  IMIS  capabilities  of  a  full  implementation  were  defined,  program 
activities  shifted  to  developing  the  demonstration  system.  During  this  phase,  a  subset  of  the 
IMIS  requirements  was  selected  for  implementation  and  demonstration.  Following  the 
successful  completion  of  the  System  Design  Review  and  the  Preliminary  Design  Review,  efforts 
were  concentrated  on  developing  a  breadboard  system  for  demonstration  at  the  Interim  Design 
Review.  The  Interim  Design  Review  and  Breadboard  Demonstration  marked  the  end  of  Phase  II. 
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ACTIVITIES 


OCD 

STATEMENT  OF  WORK 


PRODUCT 


PHASE  I:  REQUIREMENTS  ANALYSIS 


•  Research 

•  Maintenance  Scenario  Reviews 

•  Base  Visits 

•  Maintenance  Personnel  Interviews 

•  Integrated  Computer-Aided  Manufacturing 

(ICAM)  Definition  (IDEF)  Models 

•  Design  Requirements  Reviews 


SYSTEMS  ENGINEERING  ANALYSIS  (SEA) 
REPORT 

HUMAN  ENGINEERING  SYSTEM  ANALYSIS 
REPORT  (HESAR) 


PHASE  II:  DESIGN  &  DEVELOPMENT  REQUIREMENTS 


Capabilities  Assessment  Review 
Focus  on  Demonstration  vs.  Full-up  IMIS 
Working  Groups 
Design  Reviews 

Validation  of  Maintenance  Scenarios 
User  Interface 
Breadboard  Hardware 

Lessons  Learned/Update  Design  &  Documents 


SOFTWARE 

REQUIREMENTS 

SPECIFICATION 

(SRS) 


INTERFACE 

REQUIREMENTS 

SPECIFICATION 

(IRS) 


\w 


PHASE  111:  DEMONSTRATION  SYSTEM  FABRICATION 


•  Fabrication  of  Brassboard  Hardware 

•  Increase  functionality  of  Software 

•  Critical  Design  Review 

•  Lessons  Learned/Update  Design  &  Documents 


•  Fabrication  of  Demonstration  Hardware 

•  System  Integration  &  Test 


PRIME  ITEM  DEVELOPMENT 
SPECIFICATIONS  (PIDS) 

PRIME  ITEM  PRODUCT 
FABRICATION 
SPECIFICATIONS  (PIPFS) 


SOFTWARE  DESIGN 
DOCUMENT  (SDD) 


SOFTWARE  PRODUCT 
SPECIFICATION 


INTERFACE  DESIGN 
DOCUMENT  (IDD) 


FIELD  TEST  AND 
DEMONSTRATION 
(DEMO)  PLAN 


CONTRACTOR  TEST  PLAN 


SOFTWARE  TEST  PLAN 


Test  &  Demonstration 
of  Breadboard  System 


Test  &  Demonstration 
of  Brassboard  System 


Functionality  Review  of 
Demonstration  Hardware, 
Software 


PHASE  III:  FIELD  DEMONSTRATION  &  EVALUATION 


Debrief  Test 

End-to-End  Demonstration 
Fault  Isolation  Test 
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LESSONS  LEARNED/FINDINGS 


Phase  III:  Demonstration  System  Fabrication  and  Field  Evaluation 

The  main  objective  early  in  Phase  III  was  to  fabricate  and  test  a  brassboard  system  for 
demonstration  at  the  Critical  Design  Review.  Based  on  lessons  learned  from  the  breadboard  and 
brassboard  demonstrations,  the  final  software  and  hardware  designs  for  the  demonstration  system 
were  approved  (PIDS,  PIPFS,  IDD  and  SDD).  The  demonstration  hardware  and  software  were 
developed  in  accordance  with  these  approved  designs.  Extensive  system  integration  and  testing 
was  conducted  in  preparation  for  the  field  tests.  Plans  for  conducting  the  field  evaluations  and 
for  training  personnel  to  support  the  field  tests  were  developed. 

After  the  installation,  integration,  and  testing  of  the  demonstration  system  was  completed, 
three  field  tests  were  conducted  at  Luke  Air  Force  Base  (AFB):  the  Debrief  Test,  the  End-to-End 
Demonstration,  and  the  Fault  Isolation  Test.  Results  of  these  tests  and  of  this  program  were 
discussed  at  the  Final  Program  Review  and  are  documented  in  this  Final  Program  Report. 

Methodology  and  Results. 

Volume  2,  Program  Methodology,  (AL/HR-TR- 1995 -0041)  documents  the  methodology 
used  during  the  three  program  phases,  including  the  requirements  analysis,  hardware  design, 
software  design,  and  field  tests  and  demonstrations.  A  summary  of  the  results  observed  during 
the  field  tests  and  demonstrations  is  also  provided. 

Requirements  Analysis 

The  requirement  analysis  process  began  with  the  analysis  and  modeling  of  the  maintenance 
environment  and  continued  with  a  structured  methodology  for  defining  the  resulting  architecture. 
Once  the  complete  set  of  requirements  for  a  full  implementation  of  IMIS  had  been  developed,  the 
process  of  selecting  specific  requirements  to  be  implemented  in  the  demonstration  system  was 
initiated. 

The  maintenance  process  analysis  began  with  base  visits,  in  which  a  large  number  of 
maintenance  personnel  performing  a  wide  range  of  duties  and  functions  within  the  maintenance 
environment  were  interviewed.  Over  400  maintenance  personnel,  covering  29  different  Air 
Force  Specialty  Codes  (AFSCs)  and  numerous  duty  titles,  were  interviewed  at  the  following 
Tactical  Air  Command  (TAC)  and  United  States  Air  Forces  -  Europe  (USAFE)  bases  in  1989: 

Langley  AFB,  VA 
Homestead  AFB,  FL 
Hahn  AB,  FRG 
Spangdahlem  AB,  FRG 
Sembach  AB,  FRG 
Leipheim  AB,  FRG 
Ramstein  AB,  FRG 
Moody  AFB,  GA 
Shaw  AFB,  SC 
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In  addition,  interviews  were  conducted  at  Gunter  AFB;  the  Standard  Systems  Center  (SSC) 
at  Gunter  was  responsible  for  the  development  and  maintenance  of  the  Core  Automated 
Maintenance  System  (CAMS)  and  the  Standard  Base  Supply  System  (SBSS).  Through 
extensive  interaction  with  CAMS  and  SBSS  personnel,  the  IMIS  team  obtained  interface 
information  and  other  technical  data  for  each  of  these  maintenance  support  systems. 

Interviews  with  the  aircraft  maintenance  personnel  were  voluntary  and  anonymous,  were 
conducted  in  accordance  with  paragraph  30  of  Air  Force  Regulation  (AFR)  12-35,  and  complied 
with  the  Privacy  Act  of  1974.  To  aid  in  gathering  and  categorizing  information,  a  strawman 
model  was  developed  to  describe  the  maintenance  tasks  performed  by  these  personnel  between 
the  end  of  one  mission  and  the  beginning  of  the  next.  The  activities  described  in  this  model, 
derived  from  Air  Combat  Command  (ACC)  Regulation  66-5  and  coordinated  with  subject  matter 
experts  from  the  maintenance  community,  included:  obtain  aircraft  status,  allocate  resources, 
troubleshoot  aircraft,  order  parts,  repair  aircraft,  and  perform  standard  service. 

The  questionnaires  used  in  these  interviews  were  designed  to  extract  data  from  the 
maintenance  personnel  in  a  manner  that  would  lend  itself  to  the  subsequent  modeling  process. 
The  questionnaires  covered  all  aspects  of  the  six  activities  described  in  the  strawman  model.  For 
each  activity,  the  technician  was  asked  to  describe  the  tasks  performed,  the  sequencing  and 
dependencies  of  these  tasks,  how  the  tasks  are  initiated  and  completed,  what  the  results  of  the 
tasks  are,  what  data  is  needed  to  perform  the  task,  and  how  that  data  is  accessed  or  provided. 

The  information  collected  during  the  data  gathering  interviews  was  then  analyzed,  and  a 
model  of  the  maintenance  process  was  generated.  The  top-level  model  comprised  maintenance 
that  is  performed  at  the  organizational,  intermediate,  and  depot  levels.  The  primary  emphasis 
was  on  the  organizational  level,  which  focuses  on  performing  maintenance  on  the  flight  line. 
However,  there  were  interfaces  between  the  organizational  and  intermediate  levels  critical  to  the 
maintenance  process  that  needed  to  be  identified.  Also  included  were  base-level  management 
functions  performed  by  personnel  on  the  staff  of  the  Deputy  Commander  for  Maintenance 
(DCM).  As  a  result,  this  model  included  decompositions  of  the  organizational-level, 
intermediate-level,  and  staff  functions. 

Extensive  verification  and  validation  of  this  model  were  then  performed.  This  included 
internal  verification  by  different  organizations  with  varied  experience  and  backgrounds  in 
maintenance,  as  well  as  validation  with  the  user.  The  validation  of  the  model  with  the  user 
achieved  two  important  objectives:  to  develop  a  more  accurate  model  and  to  elicit  user  input  and 
contributions  to  the  modeling  effort.  The  models  were  presented  to  several  functional  work 
groups,  each  consisting  of  maintenance  personnel  with  the  same  job  title.  Any  discrepancies 
identified  during  the  validation  were  used  to  update  the  model. 

The  methodology  used  to  model  the  existing  maintenance  environment  was  a  structured 
analysis  method  based  on  Integrated  Computer-Aided  Manufacturing  (ICAM)  Definition  (IDEF), 
a  methodology  that  is  used  to  model  system  planning,  requirements  analysis,  and  system  design. 
Models  of  the  "AS-IS"  and  the  "TO-BE"  environments  were  developed  for  the  Control 
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Architecture  (CA),  which  defines  the  maintenance  functions;  the  Information  Architecture  (lA), 
which  defines  the  information  relationships;  and  the  Computer  Systems  Architecture  (CSA), 
which  defines  the  information  handling  requirements  of  the  maintenance  process. 

After  all  the  modeling  activities  had  been  completed,  the  comprehensive  requirements  for 
an  IMISA  that  represents  both  the  present  and  future  functional  characteristics  were  documented 
in  the  IMISA,  Contract  Data  Requirements  List  (CDRL)  13.  The  IMISA  consists  of  the  IMIS 
arehitectural  requirements  based  on  the  analyses  and  results  of  the  base  visits,  interviews, 
maintenance  scenarios,  maintenance  task  timelines,  and  modeling  efforts.  This  document 
contains  complete  documentation  of  the  IDEF  modeling  guidelines,  the  interview  materials  for 
the  data  gathering  trips,  and  information  from  each  of  the  six  models  (CA  “AS-IS,”  lA  “AS-IS,” 
CSA  “AS-IS,”  CA  “TO-BE,”  lA  “TO-BE,”  and  CSA  “TO-BE”). 

The  IMISA  was  then  used  as  a  primary  source  in  developing  the  SSS,  CDRL  14,  which 
establishes  the  system  definition,  performance,  design,  development,  and  test  requirements  for  a 
full  implementation  of  IMIS.  Additional  sources  include  the  IMIS  OCD,  the  Advanced  Tactical 
Fighter  (ATF)  Integrated  Maintenance  System  (AIMS)  Concept  Document,  the  Modular 
Avionics  Systems  Architecture  (MASA)  Support  Requirements  Document,  and  information  from 
previous  Air  Force  projects. 

The  requirements  listed  in  the  SSS  are  directly  traceable  to  these  sources.  Requirements 
derived  from  the  models  trace  to  actual  interviews.  This  traceability  is  essential  to  the  evolution 
of  IMIS  in  that,  as  changes  and  improvements  are  discussed,  the  models  and  underlying 
interviews  can  provide  an  understanding  of  their  possible  impacts  on  the  overall  maintenance 
process. 

The  SSS  has  been  updated  throughout  the  life  of  this  contract  to  reflect  changes  to  the  Air 
Force  organization,  changes  to  the  maintenance  environment,  and  lessons  learned  during  the 
design,  development,  and  evaluation  of  the  demonstration  IMIS. 

To  develop  a  demonstration  system  meeting  all  these  requirements  would  have  exceeded 
the  schedule  and  financial  constraints  for  the  program.  Consequently,  an  approach  for 
identifying  specific  functions  and  requirements  to  be  implemented  and  demonstrated  was 
developed.  During  a  series  of  reviews,  these  requirements  were  prioritized  and  categorized  for 
consideration  during  the  demonstrations.  This  final  list  of  requirements  was  used  as  the  basis  for 
the  hardware  and  software  design. 

The  Maintenance  Information  Workstation  (MIW)  segment  provides  an  interface  to  the 
external  data  systems  and  to  the  Portable  Maintenance  Aid  (PMA).  The  MIW  automatically 
retrieves  the  information  needed  to  perform  MIW  functions  from  the  external  sources  and 
provides  the  capability  to  transmit  data  to  these  external  sources.  The  MIW  provides  data  to  the 
PMA  to  support  the  PMA  functional  requirements,  both  at  the  beginning  of  a  task  (by  preparing 
a  cartridge)  and  during  a  task  (by  sending  data  and  messages  over  the  radio  frequency  [RF]  link). 
The  MIW  also  ser\'es  as  a  user  station  for  personnel  who  do  not  perform  their  main  tasks  on  the 
flight  line  (e.g.,  maintenance  debriefers  and  Maintenance  Operations  Center  [MOC]  personnel). 
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Hardware  Design 


Based  on  the  requirements  analysis,  the  IMIS  configuration  was  found  to  consist  of  three 
system  segments:  the  MIW,  the  PMA,  and  the  Aircraft  Interface  Panel  (AIP).  Figure  3  depicts 
the  configuration  of  the  IMIS  demonstration  system,  as  installed  at  Luke  AFB.  An  additional 
MIW  was  added  to  the  network  to  support  integration  and  demonstration  activities. 

The  PMA  segment  provides  an  interface  for  all  flightline  personnel,  both  technicians  and 
managers,  to  the  other  IMIS  segments.  The  PMA  is  used  by  managers  to  monitor  aircraft  status, 
personnel  assignments,  and  flying  and  maintenance  schedules.  The  PMA  is  used  by  the 
technicians  to  open  and  close  work  orders,  to  perform  diagnostics,  and  to  display  TOs.  The 
PMA  transmits  collected  data  to  the  MIW  for  storage,  dissemination  to  other  personnel,  and/or 
forwarding  to  external  databases,  as  required. 

TO  STANDARD  BASE-  LEVEL 


*  CD  ROM  =>  COMPACT  DISK  READ-ONLY  MEMORY 
**  CLSA  =>  COMPUTER  LOGICS  SYNCHRONOUS  ADAPTER 


Figure  3 

IMIS  Configuration 
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The  AIP  segment,  in  a  full  IMIS  implementation,  provides  the  interface  between  the  PMA 
and  the  on-board  diagnostic  computer  system.  For  the  IMIS  demonstration,  the  AIP  was  a 
portable  mockup  used  to  demonstrate  potential  applications  for  the  AIP. 


The  requirements  analysis  which  examined  the  functional  capabilities  for  each  segment 
also  took  into  consideration  the  way  in  which  the  IMIS  segments  must  interface  with  one 
another.  Each  segment  provides  multiple  methods  for  interfacing  with  the  others  to  ensure  that 
critical  data  can  be  distributed  throughout  the  system.  Figure  4  provides  an  overview  of  the 
interfaces  between  the  three  IMIS  hardware  segments  (e.g..  Radio  Standard  [RSJ-232),  as  well  as 
the  external  interfaces  with  the  F- 16  aircraft  (via  the  1553  bus)  and  the  legacy  databases  (via  the 
Standard  Base-Level  Computer  [SBLC]). 


IMIS 

SEGMENTS 


MEMORY  MODULE 


Figure  4 

IMIS  Segment  Interfaces 


Maintenance  Information  Workstation  (MIW) 

The  MIW  communicates  with  external  information  systems  and  other  IMIS  segments  to 
provide  an  integrated  source  of  information  for  all  maintenance  personnel.  The  hardware  for  the 
demonstration  system  was  selected  by  first  performing  a  trade  study  to  identify  the  commercial 
equipment  that  could  support  the  functional  requirements  and  contractual  requirements  within 
cost  constraints.  Included  in  the  list  of  functional  requirements  were  performance,  off-the-shelf 
applicability,  expandability  and  upgrades,  software  availability,  and  programmatics,  such  as  cost, 
schedule,  familiarity,  and  availability. 
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The  workstation  selected  for  the  MIW  as  a  result  of  this  trade  study  consists  of  a  Sun 
SPARCstation-2  central  processing  unit  (CPU),  a  19-inch  (4 8. 3 -centimeter)  color  display, 
keyboard,  mouse,  an  internal  1.44-megabyte  (MB)  3.5-inch  (8.9-centimeter)  floppy  disk  drive, 
and  a  207-MB  internal  Winchester  disk  drive.  Interfaces  external  to  the  main  workstation 
include  external  disk  storage  systems  which  provide  1.3  GB  of  storage  space,  an  8-mm  tape 
drive,  a  laser  printer,  and  a  compact  disk  read-only  memory  (CD  ROM).  The  network 
connection  between  the  MIWs  allows  these  devices  to  be  accessed  and  controlled  from  any 
MIW. 


Electronic  communications  between  the  MIW  and  the  local  area  network  (LAN)  is 
provided  by  an  Ethernet  connection.  This  allows  the  MIWs  to  communicate  with  one  another,  to 
communicate  with  the  Memory  Module  Loader  (MML),  and  to  be  connected  to  any  other 
computer  system  with  a  compatible  Ethernet  interface. 

An  RF  link  provides  the  interface  between  the  MIW  and  PMA  segments.  The  MIW 
interface  to  the  RF  module  is  through  the  RS-232  compatible  serial  ports.  The  PMA  and  MIW 
segments  are  also  able  to  communicate  via  an  RS-232  interface.  The  link  was  primarily  for  use 
during  development  but  is  available  to  serve  as  an  alternate  means  of  MIW-to-PMA 
communications. 

The  MIW  has  the  capability,  via  the  MML,  to  download  data  to  and  upload  data  from  a 
PMA  memory  module,  which  contains  340  MB  of  non-volatile  storage.  The  486-based  MML  is 
connected  to  the  MIW  network.  The  MML  provides  a  gateway  between  the  eentral  database, 
which  exists  in  the  SunOS  environment,  and  the  local  subset  of  the  central  database  created  for 
each  PMA  or  AIP,  which  exists  in  the  Santa  Cruz  Operation  (SCO)  Unix  environment. 

The  MIW  communicates  with  the  SBLC  via  an  RS-232  interface.  This  connection  is 
routed  through  the  Computer  Logics  Synchronous  Adapter  (CLSA)  device  and  a  series  of  9600 
baud  modems  which  send  data  to  and  receive  data  from  the  Unisys  mainframe  housing  CAMS. 

Portable  Maintenance  Aid  (PMA) 

The  PMA  collects,  processes,  and  integrates  the  data  entered  directly  or  received  through 
interfaces  with  the  MIW  and  the  AIP.  The  PMA  provides  the  maintenance  technician  detailed 
information  regarding  maintenance  tasks  while  on  the  flight  line.  The  technician,  through 
keyboard  control  and  displayed  instructions,  uses  the  PMA  to  diagnose  maintenance  faults.  The 
PMA  can  communicate  with  the  MIW  to  order  parts  and  report  status. 

The  CPU  is  a  33-megahertz  (MHz).  80486DX-based  single-board  computer.  In  addition  to 
the  basic  computer  capability,  the  single-board  computer  provides  a  video  graphics  array  (VGA) 
video  output,  two  serial  ports,  one  parallel  port,  a  hard  disk  interface,  a  PC- AT  bus  expansion 
interface,  and  a  total  of  32  MB  of  random  access  memory  (RAM).  The  original  design  called  for 
a  20-MHz,  80386SX-based  CPU  with  16  MB  of  RAM.  Early  testing  showed  that  the 
computations  performed  while  executing  the  diagnostics  algorithms  and  other  functions  required 
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additional  speed  and  memory.  The  upgraded  CPU  and  memory  provided  significant 
improvements  to  the  PMA’s  performance. 

The  display  is  a  640  x  480  VGA,  transflective  liquid  crystal  unit.  The  display  can  be 
viewed  in  direct  sunlight  without  the  use  of  a  backlight  or  in  darkness  with  a  backlight.  The 
backlight  is  integrated  into  the  display  module. 

The  PMA  uses  a  non-volatile  memory  module,  which  is  programmed  by  an  MML 
connected  to  the  MIW;  This  memory  module’s  contents  include  TO  data,  as  well  as  fault 
isolation  and  diagnostics  data  for  the  selected  subsystem.  The  memory  module  in  the  original 
design  provided  60  MB  of  storage.  As  the  technology  matured,  this  mass  storage  capacity  grew 
to  340  MB,  fitting  within  the  same  form  factor. 

Communication  between  the  PMA  and  MIW  is  accomplished  through  an  RF  link.  The  RF 
module  provides  spread  spectrum  communications  over  the  frequency  range  from  902  MHz  to 
928  MHz.  The  frequency  used  at  Luke  AFB  was  906  MHz.  The  RF  module  provides  four 
independent  channels  with  each  channel  individually  addressed.  The  RF  modules  operate  in  a 
packetized  mode  such  that  radio  control,  data,  and  status  messages  are  passed  between  the 
computer  and  RF  module  over  the  same  interface. 

The  keypad  is  a  matrix  of  membrane  switches  which  provide  the  primary  user  interface  to 
the  PMA.  These  switches  provide  tactile  feedback  and  are  resistant  to  jet  fuel  and  most  other 
solvents. 

The  battery  module  is  a  rechargeable  Nickel-Cadmium  (NiCad)  battery  pack.  This  unit 
provides  a  nominal  7.2  volts  direct  current  (DC)  output  for  use  by  the  PMA.  In  addition,  the 
battery  pack  provides  a  temperature  sensor  output  for  use  during  quick  charge.  The  PMA  may 
also  be  operated  from  an  external  power  source. 

Aircraft  Interface  Panel  (A IP) 

The  AlP  was  designed  as  a  laboratory  demonstration  unit  which  demonstrated  the 
capability  to  communicate  aircraft  information  to  the  PMA.  The  MIL-STD-1553  aircraft  internal 
time  division  command/response  multiplex  data  bus  is  used  for  this  communication,  and  the  AIP 
is  able  to  send  data  to  and  receive  data  from  the  PMA  via  this  bus.  The  AIP  uses  a  removable 
non-volatile  memory  module,  identical  to  that  used  on  the  PMA,  to  hold  its  data  files  and 
software.  This  memory  module’s  contents  include  TO  data  as  well  as  fault  isolation  and 
diagnostics  data  for  the  aircraft.  The  goal  of  the  demonstration  AIP  design  was  to  represent,  as 
closely  as  possible,  an  actual  AIP  that  would  be  embedded  in  an  aircraft. 

When  these  requirements  were  delineated,  it  was  noted  that  the  demonstration  AIP 
required  functionality  which  was  very  similar  to  that  of  the  PMA.  As  a  result,  it  was  decided  that 
the  AIP  would  use  the  internal  components  of  the  PMA  to  the  extent  possible.  In  fact,  with  the 
exception  of  the  RF  modem  (required  on  the  PMA  but  not  on  the  AIP),  the  internal  electronics  of 
the  two  devices  are  identical. 
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Since  the  AIP  was  a  functional  mockup  of  a  device  which  would  eventually  be  installed  on 
an  aircraft,  its  chassis  design  was  quite  different  from  that  of  the  PMA.  The  AIP  was  housed  in  a 
metal  chassis  which  gave  the  appearance  of  a  line  replaceable  unit  (LRU).  Handles  were  placed 
on  the  front  to  allow  easy  removal  and  replacement. 

Software  Design 

The  IMIS  software  has  been  designed  to  support  the  complex  maintenance  tasks  that  are 
performed  by  the  0-Level  maintenance  personnel  by  processing,  integrating,  and  displaying 
information  from  various  sources.  IMIS  interfaces  with  external  systems  and  supports  their  data 
and  operational  requirements,  thereby  providing  a  single  system  with  which  maintenance 
personnel  can  perform  their  day-to-day  maintenance  activities. 

IMIS  allows  the  user  to  extract  many  combinations  of  information  without  requiring 
complicated  command  sequences.  By  providing  simple  access  to  this  information,  IMIS 
facilitates  the  user's  ability  to  perform  troubleshooting,  maintenance  analysis,  and  decision 
support.  IMIS  also  has  the  ability  to  interface  with  the  F-16  C/D  Block  40/42  on-board 
diagnostics  and  to  translate  information  received  during  fault  verification  for  use  in  fault 
isolation. 

The  IMIS  Computer  Software  Configuration  Item  (CSCI)  encapsulates  all  the  software 
functions  associated  with  the  user  interface,  maintenance,  management,  and  diagnostics 
capabilities  as  described  in  the  Software  Requirements  Specification  (SRS).  The  purpose  of  the 
IMIS  CSCI  is  to  specify  a  single  software  design  in  terms  of  abstractions  (system  classes)  and 
generic  services  that  can  be  used  as  the  baseline  for  modification  to  execute  on  all  the  MIW, 
PMA,  and  AIP  components  of  IMIS.  Thus,  the  need  to  specify  a  unique  software  design  for  each 
IMIS  component  is  avoided. 

An  object-oriented  development  approach  was  used  for  IMIS  to  take  maximum  advantage 
of  the  benefits,  including  reusability  and  extensibility.  Given  the  nature  of  the  IMIS  program,  it 
was  believed  that  the  object-oriented  path  would  provide  the  greatest  benefit  during  the 
development  of  the  demonstration  system  and  extending  into  the  full  system  development. 

The  IMIS  software  development  environment  was  chosen  to  support  object-oriented 
analysis,  design,  and  programming.  The  IMIS  software  development  environment  is  an 
integrated  environment  centered  on  the  ONTOS  object-oriented  database  as  the  central 
repository.  Associative  Design  Technology’s  Ptech  was  selected  to  act  as  the  front  end  for  the 
object-oriented  database  repository.  This  provided  a  high  degree  of  integration  for  the  design 
representations,  in  that  the  conceptual  models  go  directly  into  the  ONTOS  database  in  terms  of 
class  libraries  and  process  implementations. 

Two  constraints  were  considered  in  selecting  C++  and  C  as  the  programming  languages  for 
the  IMIS  software  development  environment.  The  first  constraint  was  that  a  custom  application 
communicating  with  ONTOS,  the  IMIS  object-oriented  database,  can  be  written  using  C++,  but 
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not  C.  The  second  constraint  is  that  the  Sybase  Application  Programming  Interface  (API),  used 
in  the  External  Data  Management  software,  can  be  invoked  by  applications  written  in  C  but  was 
not  recommended  for  applications  written  in  C++.  Consequently,  all  IMIS  software  has  been 
written  in  C++,  with  the  exception  of  various  external  data  management  functions,  written  in  C, 
which  invoke  the  Sybase  API. 

IMIS  is  a  multi-user  application  that  operates  on  the  MIW,  PMA,  and  AIP.  The  IMISA 
provides  the  user  with  functionality,  data,  and  a  user  interface  that  are  consistent  across  these 
different  platforms.  The  IMISA  consists  of  transactions  and  services  that  share  a  common  class 
library.  The  services  and  transactions  are  the  processes  which  access  and  manipulate  the  class 
library.  The  class  library  contains  all  reusable  components  of  IMIS  software.  The  system  is 
configured  so  that  an  IMIS  process  executes  on  each  platform  in  the  system.  This  provides  a 
consistent  interface  to  the  user. 

The  IMIS  User  Interface  (UI)  software  was  designed  to  be  as  reusable  as  possible,  from 
both  a  development  perspective  and  a  user-friendly  perspective.  The  initial  set  of  UI  paradigms 
was  identified  based  on  a  knowledge  of  project  requirements,  high-level  system  design,  and 
prototyping  efforts.  These  paradigms  were  generic  and,  therefore,  reusable  across  a  wide  variety 
of  applications.  Specific  screen  states  and  state  transition  diagrams  were  developed  with  these 
generic  paradigms  in  mind.  This  process  maximized  software  reuse  in  terms  of  object-oriented 
software  classes  and  reusable  widgets. 

User  interface  transactions  developed  for  the  IMIS  application  covered  all  aspects  of  the 
maintenance  environment.  Only  a  subset  of  these  transactions  was  exercised  during  the  field 
demonstrations  at  Luke  AFB.  These  transactions  included  Debrief,  Open  Work  Order,  Task 
Assignment,  FS  Aircraft  Status,  Work  Order  History,  Close  Work  Order,  Display  Flying 
Schedule,  Display  Maintenance  Schedule,  Order  Parts  (via  both  the  Quick  Reference  List  and  the 
Illustrated  Parts  Breakdown),  Prepare  and  Extract  PMA  Cartridge,  and  Send  and  Display 
Messages. 

The  IMIS  Diagnostics  Module  (IMIS-DM)  assists  the  maintenance  technician  by  making 
maintenance  action  recommendations  for  diagnosing  and  repairing  a  faulty  aircraft  in  minimum 
time.  In  making  its  recommendations,  IMIS-DM  considers  accrued  test  results  and  system 
knowledge,  with  decisions  guided  by  a  predefined  model  of  aircraft  symptoms,  faults,  test,  and 
repairs,  created  in  accordance  with  a  customized  version  of  the  Air  Force  Content  Data  Model 
(CDM),  version  6. Ox.  This  data  is  stored  in  and  accessed  through  the  IMIS  object  database. 

The  Technical  Order  Presentation  (TO  Present)  system  (developed  by  the  Lockheed  Fort 
Worth  Compnay  [LFWC])  provides  the  means  to  interactively  display  TOs  to  the  user.  To 
provide  this  specialized  functionality  in  as  seamless  a  fashion  as  possible,  TO  Present  appears  as 
a  subprocess  within  IMIS,  with  state  information  and  certain  functions  in  higher-level 
subprocesses  accessible  within  TO  Present.  The  thread  mechanism  is  used  to  break  TO  Present 
into  subparts  which  communicate  with  each  other  and  with  IMIS. 
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For  personnel  using  IMIS  to  make  accurate  and  informed  decisions  regarding  their 
assigned  maintenance  tasks,  it  is  critical  to  have  reliable  and  consistent  process-to-process 
communication.  The  Message  Manager  is  responsible  for  maintaining  consistency  between  the 
MIW  shared  database  and  the  PMA  local  databases.  The  Message  Manager  also  sends  updates 
to  the  MML  copy  of  the  shared  database,  which  is  used  for  downloading  memory  modules.  The 
Message  Manager  operates  over  the  RF  link  and  over  the  network. 

The  External  Data  Management  (EDM)  interface  runs  on  the  MIW  and  serves  as  the 
interface  between  the  IMIS  object  database  and  CAMS,  the  legacy  system.  The  main  function  of 
the  EDM  interface  is  to  maintain  consistency  between  IMIS  and  CAMS.  User-induced  changes 
to  IMIS  data  which  is  also  resident  in  CAMS  must  be  made  to  CAMS,  and  data  from  CAMS  or 
SBSS  must  be  retrieved  periodically  for  display  to  the  IMIS  user.  The  IMIS  object  database  is 
initialized  with  data  needed  from  CAMS;  thereafter,  consistency  is  maintained  with  batch 
scheduled  updates. 

The  IMIS  software  was  designed  so  that  the  type  of  hardware  platform  would  have 
minimal  impact  on  the  available  functionality.  Some  software,  however,  had  to  be  developed 
specifically  for  the  PMA,  due  to  the  unique  capabilities  required  for  that  platform.  In  particular, 
it  was  critical  to  develop  the  ability  for  the  PMA  to  interface  with  the  aircraft  1553  bus,  allowing 
the  user  to  initiate  built-in  test  (BIT)  on  the  three  aircraft  subsystems  selected  for  the 
demonstration  (Fire  Control  Radar  [FCR],  Head-Up  Display  [HUD],  and  Inertial  Navigation  Set 
[INS])  and  view  the  results. 

Field  Tests  and  Demonstrations 

Following  the  system  integration  and  test  of  the  hardware  and  software  described  in  the 
previous  sections,  the  IMIS  demonstration  system  was  installed  at  Luke  AFB,  AZ,  to  begin  the 
field  evaluation  phase.  The  IMIS  Field  Test  and  Demonstration  was  separated  into  three 
segments:  Debrief  Test,  End-to-End  Demonstration,  and  Fault  Isolation  Test.  The  primary 
objectives  of  these  activities  were:  to  test  the  IMIS  concept  under  realistic  operational  conditions 
where  possible,  to  evaluate  the  effectiveness  of  IMIS  in  supporting  the  maintenance  mission  of 
the  unit,  to  demonstrate  the  technical  advantages  of  IMIS  over  the  current  system,  and  to  identify 
strengths  and  weaknesses  of  the  demonstration  system  which  could  be  used  in  defining 
requirements  for  a  production  implementation.  The  following  sections  describe  the  objectives 
and  methodology  of  each  of  these  tests. 

Debrief  Test.  The  Debrief  Test  was  the  first  test  of  the  IMIS  demonstration  system 
condueted  at  Luke  AFB,  AZ.  It  was  a  six-week  evaluation  period  during  November  and 
December  1993. 

The  primary  objective  of  the  Debrief  Test  was  to  evaluate  the  IMIS  debrief  capability 
under  realistic  conditions.  The  Debrief  Test  was  accomplished  by  observing  and  timing  a 
relatively  large  number  of  real  (not  simulated)  debrief  sessions.  One  half  of  the  debriefs  used 
IMIS  and  the  other  half  using  the  current  method.  The  debriefs  were  performed  by  maintenance 
personnel  using  actual  sorties  and  pilots.  The  data  collected  was  compared  to  debriefs  performed 
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using  IMIS  with  those  performed  using  the  current  method.  The  data  collected  during  each  pilot 
debrief  session  included  start  and  stop  times,  problems  encountered,  and  observations.  Data 
collected  about  each  discrepancy  included  the  Job  Control  Number  (JCN),  Work  Unit  Code 
(WUC),and  if  the  pilot  reported  additional  data  about  the  discrepancy. 

After  completion  of  the  debrief  session,  a  maintenance  data  collector  tracked  all  reported 
discrepancies  through  the  maintenance  system  to  determine  what  maintenance  actions,  if  any, 
were  taken  to  correct  each  discrepancy  and  which  discrepancies  turned  out  to  be  CNDs  or 
RTOKs.  At  the  end  of  the  Debrief  Test,  the  maintenance  debriefers  were  asked  to  complete  two 
questiormaires  soliciting  their  evaluation  of  the  system  and  recommendations  for  changes  or 
improvements. 

End-to-End  Demonstration.  The  End-to-End  Demonstration  was  a  demonstration  of  the 
primary  functions  of  IMIS.  This  demonstration  was  conducted  at  Luke  AFB,  AZ,  from  June  1- 
through  June  30,  1994. 

The  End-to-End  Demonstration  was  to  illustrate  to  the  users  the  overall  IMIS  concept  by 
using  the  system  to  support  a  series  of  typical  scenarios  of  maintenance  activities,  under 
structured  conditions,  in  an  operational  environment.  The  End-to-End  Demonstration 
demonstrated  system  functional  capabilities  in  all  primary  IMIS  functional  areas:  debrief, 
diagnostics,  electronic  TOs,  work  order  generation  and  close-out,  and  flightline  management 
support. 

The  primary  objectives  of  the  End-to-End  Demonstration  were  to  (1)  evaluate  the  overall 
IMIS  concept  by  exercising  IMIS  capabilities  in  all  functional  areas,  (2)  obtain  user  feedback  in 
each  primary  functional  area,  (3)  observe  the  system  in  operation  under  conditions  approaching 
those  in  the  real  world  of  aircraft  maintenance,  (4)  and  identify  candidate  changes/improvements 
needed  for  a  fully  implemented  IMIS 

Scenarios  intended  to  demonstrate  the  maintenance  functionality  were  developed  for  the 
production  superintendent,  airplane  general  (APG)  expediter,  specialist  expediter,  debriefer,  and 
maintenance  technician.  These  scenarios  required  each  participant  to  perform  a  series  of  tasks 
using  IMIS.  The  actions  were  designed  to  cause  the  participant  to  exercise  those  functions 
available  in  IMIS  to  do  their  assigned  tasks.  For  example,  the  specialist  expediter  received  a 
work  order  through  IMIS  and  was  required  to  assign  a  technician  to  the  job.  Similarly,  the 
production  superintendent  received  a  request  for  authorization  to  order  a  part,  and  was  required 
to  respond  to  that  request.  The  scenarios  were  designed  to  overlap  so  that  an  action  by  one 
participant  might  require  another  participant  to  take  action.  For  example,  the  maintenance 
debriefer  created  the  work  order  to  which  the  specialist  expediter  responded. 

Four  personnel,  when  available,  were  tested  in  each  session:  an  APG  expediter,  a 
specialist  expediter,  a  production  superintendent,  and  a  maintenance  debriefer.  After  being 
trained,  each  subject  then  followed  the  scenario  designed  to  exercise  the  IMIS  functions  relevant 
to  his  or  her  job.  The  exercises  required  the  subjects  to  deal  with  the  messages  previously  loaded 
on  the  PMA  cartridge.  They  were  also  told  to  expect  new  messages  via  RF  while  they  were 
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going  through  the  scenario.  After,  the  scenario  was  completed,  the  subjects  were  allowed  to 
experiment  on  their  own  and  to  try  other  features  of  IMIS,  with  the  assistance  of  the  trainer. 

When  each  subject  was  through  with  the  scenario,  two  questionnaires,  to  elicit  their 
reaction  to  various  IMIS  features  and  characteristics,  and  a  workload  assessment  instrument,  the 
National  Aeronautics  and  Space  Administration  (NASA)  Task  Load  Index  (TLX),  were 
completed.  The  first  questionnaire  was  a  lengthy  set  of  subjective  questions  about  IMIS  in 
general,  presented  by  the  computer,  with  answers  on  a  sliding  scale  which  were  easily  marked 
with  a  mouse  or  pointing  device  by  the  participant.  The  NASA  TLX  is  a  method  of  collecting 
information  on  individual  maintenance  segments,  such  as  troubleshooting,  debrief,  scheduling, 
and  so  forth,  of  the  IMIS  demonstration.  After  each  segment,  the  user  was  presented  with  a  set 
of  questions  to  determine  the  amount  of  workload  he  or  she  experienced  with  that  segment.  The 
results  were  automatically  tabulated  at  the  end  of  each  set  to  determine  which  segments  caused 
the  most  workload  stress. 

Fault  Isolation  Test.  The  Fault  Isolation  Test  was  the  final  field  test  of  the  IMIS 
demonstration  system  conducted  at  Luke  AFB,  AZ,  in  August  and  September  1994.  The  purpose 
of  the  Fault  Isolation  Test  was  to  determine  whether  performance  improvements  could  be 
achieved  in  several  inefficient  areas  identified  in  the  current  maintenance  process.  For  example, 
by  (1)  providing  a  technician  a  single  PMA  cartridge  which  contains  all  the  current  TO  data 
needed  to  perform  a  task,  the  taisk  preparation  and  completion  time  could  be  reduced;  (2) 
providing  the  capability  to  initiate  and  approve  a  part  order  from  the  flightline,  the  maintenance 
process  could  become  more  efficient;  or  (3)  collecting  maintenance  data  during  a  diagnostics 
session  and  allowing  the  work  order  to  be  closed  from  the  flightline,  the  technician’s  time 
required  to  complete  paperwork  and  interact  with  CAMS  can  be  substantially  reduced. 

The  primary  objectives  of  the  Fault  Isolation  Test  were  to  evaluate  aspects  of  each  of  the 
tests  to  determine  the  effectiveness  of  IMIS  in  supporting  the  diagnostic  and  repair  processes, 
and  to  determine  improvements  to  make  in  future  systems.  These  objectives  were  accomplished 
(1)  by  quantitatively  comparing  each  participant’s  performance  using  IMIS  versus  using  the 
current  paper  TOs  and  (2)  by  comparing  user  acceptance  of  IMIS  versus  the  paper  TOs. 

The  Fault  Isolation  Test  was  designed  using  three  subsystems  that  are  supported  by  data 
authored  for  IMIS:  FCR,  HUD,  and  INS.  Simulated  faults  were  inserted  into  the  aircraft 
subsystems,  and  technicians  were  required  to  diagnose  and  simulate  correcting  the  discrepancies. 
Twenty-four  technician  participants  performed  twelve  fault  isolation  tasks  (four  on  each  of  the 
three  subsystems).  Two  of  the  tasks  for  each  subsystem  were  performed  using  the  paper  TOs  as 
job  performance  aids,  and  the  remaining  two  tasks  used  the  IMIS  PMA.  No  participant 
performed  the  same  task  more  than  once.  Twelve  subjects  were  qualified  in  avionics 
maintenance  specialties;  the  remaining  twelve  were  qualified  crew  chiefs. 

Quantitative  measures  were  gathered  by  data  collectors  observing  each  technician's 
performance  of  each  maintenance  task.  Data  was  collected  according  to  a  structured  protocol  for 
each  maintenance  task.  Time  values  were  corrected  for  instances  beyond  the  control  of  the 
evaluation  team,  such  as  transportation  delays,  support  equipment  malfunctions,  and  so  forth. 
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Qualitative  and  descriptive  measures  were  collected  primarily  through  structured  question  sets  on 
data  collection  forms.  Qualitative  measures  included  experience  level  of  subjects,  specific 
problems  encountered  in  using  technical  information  (either  TOs  or  the  PMA)  to  perform 
maintenance  tasks,  information  from  short  debriefings  of  each  technician  after  performing  each 
maintenance  task,  and  information  from  a  technical  information  evaluation  questionnaire  and 
structured  interview  administered  after  maintenance  tasks  had  been  performed. 

Data  was  collected  in  the  310th  Fighter  Squadron  (FS)  over  a  span  of  30  workdays.  Each 
subject  was  assigned  to  participate  in  the  test  for  five  workdays.  On  the  first  of  the  five  days, 
subjects  were  trained  in  the  use  of  paper  TOs,  in  the  use  of  IMIS,  and  in  the  conduct  of  the  test. 
On  the  remaining  four  days,  each  subject  performed  an  average  of  three  tasks  per  day.  Four 
subjects  performed  troubleshooting  tasks  on  an  actual  F-16  aircraft  each  day:  two  on  the  day 
shift  and  two  on  the  swing  shift.  Two  teams  of  data  collectors  gathered  performance  data,  one 
team  assigned  to  each  shift. 

Results 

The  results  of  the  Debrief  Test,  the  End-to-End  Demonstration,  and  the  Fault  Isolation  Test 
are  summarized  in  the  following  subsections. 


Debrief  Test.  The  Debrief  Test  was  conducted  at  Luke  AFB  from  November  3  through 
December  9,  1993.  Data  was  collected  by  observing  and  timing  actual  debrief  sessions,  some 
using  IMIS  and  the  rest  using  the  current  method.  Four  maintenance  debriefers  participated  to 
varying  degrees  over  the  six- week  period;  only  two  debriefers  were  involved  in  the  majority  of 
the  debrief  sessions.  Information  collected  during  the  sessions  included  start  and  stop  times, 
problems  encountered,  discrepancy  data  (for  use  in  subsequent  tracking  of  work  orders),  and 
observations  or  remarks. 

The  data  for  the  Debrief  Test  was  collected  by  observing  live  debrief  sessions,  therefore, 
the  Debrief  Test  could  not  be  designed  to  provide  a  statistically  valid  test  of  various  hypotheses. 
Instead,  a  quantitative  comparison  of  the  data  was  performed  to  determine  trends  in  the  debrief 
data  collected  using  IMIS  and  the  current  method.  The  data  collected  and  the  results  are 
summarized  in  the  following  subsections. 

IMIS  Debrief  Results.  Forty-five  debrief  sessions  using  IMIS  were  observed; 
discrepancies  were  reported  in  only  thirteen  of  these.  Because  of  this  small  number,  conclusions 
regarding  the  quantities  of  work  orders  opened  and  the  effectiveness  of  the  discrepancy 
information  captured  could  not  be  supported.  Minor  problems  were  identified  during  the  IMIS 
debrief  sessions.  These  included  discrepancies  in  the  authored  Fault  Reporting  Manual  (FRM) 
data,  recommended  software  enhancements  (especially  involving  facilitating  error  correction), 
and  environmental  difficulties  resulting  when  inundated  with  pilots  to  be  debriefed.  None  of 
these  problems  significantly  affected  the  outcome  of  the  debrief  sessions. 
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Paper  Debrief  Results  One  hundred  and  eleven  debrief  sessions  using  the  current 
system  were  observed.  Data  from  two  of  these  sessions  was  incomplete  or  inconsistent  and  was 
discarded,  leaving  a  total  of  109  data  points.  The  problems  encountered  during  some  of  these 
debriefs  centered  primarily  on  CAMS.  In  one  case,  CAMS  rejected  a  debrief  because  the 
maintenance  debriefer  had  not  been  notified  of  a  tail  number  swap.  Several  other  sessions 
reported  CAMS  as  performing  slowly,  taking  an  extremely  long  time  between  screens,  and  not 
accepting  input.  These  problems  added  to  the  overall  debrief  times,  since  debriefer  interaction 
was  required. 

Comparison  of  Debrief  Results.  When  comparing  the  data  collected  during  the 
Debrief  Test,  some  clear  trends  were  evident.  A  summary  of  the  comparison  data  can  be  found 
in  Table  1,  which  lists  average  times  and  sample  sizes  for  each  categorization  of  the  data.  Again, 
it  is  important  to  note  that  the  data  was  not  collected  in  accordance  with  a  statistically  valid 
experimental  design,  so  that  a  comparison  with  any  level  of  statistical  significance  is  not 
possible. 


Table  1.  Comparison  of  Results 


IMIS 

Current  Method 

Debrief  Time  (All) 

5:56  (45  debriefs) 

13:26(109) 

Pilot  Time  (All) 

3:57  (45) 

4:36  (109) 

Debrief  Time  (Code  1  Only) 

3:15  (32) 

9:36  (56) 

Pilot  Time  (Code  1  Only) 

2:58  (32) 

3:26  (56) 

Debrief  Time  (Code  2,  3) 

12:32(13) 

17:29  (53) 

Pilot  Time  (Code  2,  3) 

6:23  (13) 

5:50  (53) 

Debrief  Time  (1  Work  Order) 

9:27  (11) 

14:05  (37) 

Pilot  Time  (1  Work  Order) 

5:05  (11) 

5:19  (37) 

Debrief  Time  (>1  Work  Order) 

29:30  (2) 

25:23  (16) 

Pilot  Time  (>1  Work  Order) 

13:30  (2) 

7:00  (16) 

Overall,  the  debrief  time  using  IMIS  was  less  than  half  that  using  the  current  method  (5:56 
vs.  13:26).  The  pilot  time  considering  all  data  was  also  less,  although  the  difference  was  not 
nearly  as  dramatic  (3:57  vs.  4:36). 

For  only  Code  1  debriefs  (i.e.,  no  discrepancies  reported),  the  total  debrief  time  is  reduced 
by  a  factor  of  two-thirds  when  using  IMIS  (3:15  vs.  9:36).  In  these  cases,  the  completion  of  the 
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IMIS  debrief  required  only  an  additional  17  seconds  after  the  pilot  was  done  (2:58  vs.  3:15),  as 
compared  to  the  current  method,  where  an  additional  six  minutes  was  required  (3:26  vs.  9:36). 

In  debriefs  where  discrepancies  were  reported  and  work  orders  were  opened,  the  pilot  time 
was  not  less  when  using  IMIS  compared  to  the  current  method  (6:23  vs.  5:50).  The  33  second 
delay  was  because  the  pilot  was  present  as  each  work  order  was  opened  and  as  the  appropriate 
entry  from  the  FRM  data  was  selected.  The  overall  debrief  time  for  these  debriefs  was  still  less 
(12:32  vs.  17:29). 

The  data  when  considering  debriefs  where  a  single  work  order  was  opened  is  similar. 
Because  of  the  small  number  of  debriefs  where  multiple  work  orders  were  opened  using  IMIS 
(only  two),  no  comparisons  can  be  made. 

User  Feedback.  The  user  feedback  provided  after  the  completion  of  the  Debrief  Test 
was  very  valuable.  When  asked  what  they  liked  most  about  the  IMIS  debriefing  function,  the 
maintenance  debriefers  stated  that  conducting  a  debrief  session  for  a  Code  1  (no  discrepancies) 
aircraft  was  extremely  fast,  aided  especially  by  the  pre-filling  of  data  elements  from  the  flying 
schedule  and  by  the  availability  of  pull  down  menus  to  select  data  and  minimize  data  entry 
errors.  They  noted  that  the  enhanced  question  sets  used  when  opening  a  work  order  were  helpful 
to  technicians  when  they  were  not  qualified  for  or  familiar  with  a  particular  discrepant  aircraft 
system.  They  felt  that  anyone  could  debrief  a  system  with  the  enhanced  question  sets  to  assist  in 
the  debrief  process.  However,  the  enhanced  question  sets  were  also  viewed  somewhat  as  a 
negative  factor,  since  this  required  additional  time  when  debriefing  a  Code  2  or  Code  3  aircraft. 

The  maintenance  debriefers  also  made  several  recommendations  regarding  functionality 
enhancements  which  would  make  the  system  even  better,  including  the  ability  to  interactively 
update  the  enhanced  question  sets.  The  debriefers  also  noted  that  they  must  frequently  update 
the  debrief  results  in  CAMS  when  new  or  revised  information  becomes  available;  providing  the 
capability  to  edit  debrief  data  in  IMIS  after  it  has  been  accepted  would  make  the  debrief  process 
more  efficient.  Flying  schedule  and  tail  number  swaps  occurred  frequently  during  the  Debrief 
Test,  and  IMIS  demonstrated  limited  ability  to  respond  to  these  last-minute  changes.  The 
debriefers  felt  it  would  be  desirable  to  provide  the  capability  to  debrief  a  tail  number  which  is 
not  on  the  list  of  undebriefed  sorties  rather  than  to  wait  for  the  change  to  be  entered  into  CAMS 
and  propagated  to  IMIS  manually. 

End-to-End  Demonstration.  The  IMIS  End-to-End  Demonstration  was  a  field 
demonstration  of  the  primary  functions  of  IMIS.  This  demonstration  was  conducted  on  F-16 
Block  40/42  aircraft  assigned  to  the  310th  FS  at  Luke  AFB,  AZ  from  1  June  through  30  June 
1994.  It  was  intended  to  illustrate  to  users  the  overall  IMIS  concept  by  using  the  system  to 
support  a  series  of  typical  maintenance  scenarios  in  an  operational  environment,  under  structured 
conditions.  It  demonstrated  system  functional  capabilities  in  all  primary  IMIS  functional  areas: 
debrief,  diagnostics,  electronic  TOs,  work  order  generation/close-out,  and  flightline  management 
support. 
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The  basic  objectives  of  the  End-to-End  Demonstration  were  achieved  with  the  validation  of 
the  IMIS  concept.  The  demonstration  showed  that  IMIS  does  effectively  provide  information 
that  the  technicians  require,  that  it  provides  information  in  a  way  that  is  acceptable  to  them,  and 
that  it  is  something  they  want.  The  participants  also  provided  valuable  feedback,  including 
suggestions  for  improving  the  system,  as  well  as  suggestions  for  improving  the  content  and 
organization  of  data  presented  by  the  system. 

A  total  of  32  participants,  including  expediters,  production  superintendents,  maintenance 
debriefers,  and  technicians,  completed  the  exercise.  All  the  participants  either  were  currently 
performing  in  the  job  they  represented  or  had  recent  experience  in  that  position.  Three  types  of 
data  were  collected  from  the  participants:  an  exit  questioimaire,  an  automated  questionnaire  that 
collected  opinions  on  IMIS  functional  characteristics,  and  the  NASA  TLX. 

Exit  Questionnaire  Results.  The  exit  questionnaire  contains  three  direct  questions 
and  a  place  for  the  respondent  to  add  written  comments.  The  participants  readily  recognized  that 
the  current  demonstration  system  is  intended  only  for  use  in  evaluating  the  concept  of  an  IMIS  as 
a  tool  for  establishing  requirements  for  a  system  to  be  developed  for  operational  use. 
Consequently,  they  were  able  to  evaluate  the  system  on  its  potential.  Overall  responses  to  the 
questionnaire  indicate  a  positive  reaction  to  the  IMIS  concept.  Many  of  the  responses  were  very 
laudatory.  The  only  exceptions  were  comments  directed  toward  weaknesses  in  the 
demonstration  system. 

When  asked  what  they  liked  about  IMIS  as  an  aid  to  help  them  do  their  jobs,  the 
participants  responded  that  they  were  impressed  with  the  amount  of  information  available 
through  IMIS,  and  that,  with  a  few  key  strokes,  they  could  quickly  access  information  which  they 
would  normally  have  to  track  down  manually.  They  noted  that  not  only  are  schedules  and 
similar  information  kept  current  but  key  people  are  notified  of  changes.  They  were  especially 
pleased  that  they  did  not  have  to  work  directly  with  CAMS  to  extract  or  input  data,  since  IMIS 
interfaces  with  CAMS  and  enters  the  data  automatically.  The  availability  of  all  required  TOs  on 
the  PM  A  and  the  ability  to  access  parts  information  were  also  seen  as  benefits  to  the  users. 

When  asked  what  they  did  not  like  about  IMIS,  participants  most  often  cited  speed. 
However,  respondents  differed  in  their  perception  of  the  impact  of  speed,  noting  that  the 
response  times  were  still  considerably  less  than  the  times  required  to  perform  those  same 
functions  today.  A  lack  of  consistency  in  the  use  of  certain  function  keys  caused  some 
confusion.  Furthermore,  many  participants  encountered  difficulty  using  the  PM  A  keypad,  which 
required  a  firm  press;  it  was  easy  to  think  a  function  had  been  activated  when,  in  fact,  it  had  not. 
The  PMA  was  also  prone  to  software  failures  during  the  End-to-End  Demonstration.  These 
problems  were  documented  and  most  were  corrected  before  the  Fault  Isolation  Test  began. 

Characteristics  Questionnaire  Results.  The  characteristics  questioimaire  consisted 
of  97  questions  designed  to  measure  participants'  evaluations  of  various  characteristics  of  the 
IMIS  demonstration  system.  The  questionnaire  required  the  participant  to  indicate  the  degree  of 
agreement  with  a  statement  about  an  IMIS  characteristic.  The  response  was  made  on  a  seven- 
point  scale.  The  complete  questionnaire  covered  all  key  features  and  characteristics  of  the  IMIS. 
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The  rating  scale  used  ranged  from  1  (very  positive)  to  7  (very  negative).  The  participants  only 
responded  to  questions  on  features  which  they  had  experienced  during  the  demonstration. 
Consequently,  from  a  total  of  97  questions,  41  were  relevant  during  the  End-to-End 
Demonstration.  Some  of  these  41  questions  were  determined  to  have  been  incorrectly  structured 
and  were  subsequently  eliminated,  reducing  the  total  number  of  questions  to  35. 

Questionnaire  results  indicate  that  responses  are  generally  consistent  with  respondents' 
answers  to  the  exit  questionnaire.  Overall,  responses  were  positive.  The  total  overall  rating  for 
all  responses  was  3.01.  Nineteen  of  the  questions  were  classified  as  either  very  positive  or 
positive.  Three  items  were  classified  as  negative  (none  were  classified  as  very  negative). 
Ratings  for  the  remaining  thirteen  questions  were  classified  as  neutral.  A  review  of  all  responses 
showed  that  the  items  receiving  positive  ratings  include  those  concerning  the  manner  in  which 
information  was  presented  on  the  PMA,  procedures  for  accessing  information,  and  techniques  for 
interacting  with  the  system.  Most  of  the  negative  ratings  related  to  the  specific  characteristics  of 
the  demonstration  PMA,  specifically  the  responsiveness  of  the  keypad  and  the  reliability  of  the 
RFlink. 


NASA  Task  Load  Index  Results.  The  NASA  TLX  is  a  multidimensional  workload 
assessment  tool  designed  to  provide  a  measure  of  the  workload  imposed  by  a  given  job/work 
situation.  The  index  is  composed  of  weighted  subscores  of  ratings  on  six  factors  which  are 
believed  to  contribute  to  workload.  The  factors  are:  mental  demands,  physical  demands, 
temporal  demands,  own  performance,  effort,  and  frustration.  The  NASA  TLX  produces  a 
workload  measure  for  each  factor  plus  a  cumulative  index  of  workload.  Each  index  can  range 
from  0  to  100  and  represents  a  measure  of  the  workload  imposed  by  the  job/work  situation. 

By  completing  the  NASA  TLX  twice  (once  using  the  current  paper-based  methods  as  the 
frame  of  reference  and  once  using  IMIS),  it  was  possible  to  measure  the  relative  workload 
imposed  by  the  two  work  situations.  Complete  NASA  TLX  ratings  were  made  by  16  subjects. 
Analysis  of  the  ratings  yielded  a  mean  TLX  workload  index  of  62.75  for  the  paper-based 
condition  and  44.44  for  the  IMIS  condition.  The  difference  between  means  is  statistically 
significant  at  the  .0001  confidence  level. 

The  results  suggest  that  for  this  End-to-End  Demonstration,  IMIS  significantly  reduced  the 
workload  experienced  by  expediters  and  production  superintendents,  reinforcing  the  results  from 
previous  field  tests.  However,  caution  should  be  used  in  interpreting  the  NASA  TLX  results 
because  they  are  based  upon  a  relatively  small  sample  and  the  paper-based  ratings  are  based  on 
retrospection  rather  than  immediate  experience. 

Other  Activities/Results.  The  PMA  RE  capability  was  tested  by  transmitting  and  receiving 
messages  from  the  PMA  to  the  IMIS  base  antenna  located  on  the  310th  FS  hangar  (Building 
913).  Transmissions  were  made  at  distances  of  up  to  2500  feet  (762  meters),  sufficient  to  cover 
the  310th  FS  aircraft  parking  area.  No  problems  were  encountered  in  transmitting  messages  at 
these  distances.  In  addition,  the  RF  capability  was  tested  with  up  to  four  PMAs  sending  and 
receiving.  No  problems  were  encountered.  However,  it  became  apparent  that  the  more  PMAs  in 
operation,  the  slower  the  transfer  of  messages  between  the  PMAs  and  the  base  station.  Also, 
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using  the  RF  slows  down  non-RF  related  processes  on  the  PMAs  because  the  PMA  has  to 
interrupt  ongoing  processes  to  receive  messages  and  updates. 

The  PMAs  were  installed  in  the  expediter  vehicle  and  tested  without  problems.  It  was  also 
installed  in  the  production  superintendent's  vehicle  but  not  used  for  transmissions.  Some  minor 
modifications  for  the  moimting  racks  were  identified. 

The  PMA  was  not  formally  tested  for  heat  tolerance  during  the  End-to-End  Demonstration; 
however,  it  was  used  under  high-temperature  conditions.  It  was  used  in  an  expediter  truck 
without  air  conditioning  in  ambient  temperatures  up  to  1 17°F  (47°C).  In  addition,  it  was  used  in 
a  hangar  environment  for  several  hours  per  session  in  temperatures  up  to  110°F  (43 °C).  No 
problems  were  encountered  with  the  PMAs  due  to  heat. 

Fault  Isolation  Test.  The  results  from  the  Fault  Isolation  Test  are  documented  in  a 
separate  Armstrong  Laboratory  reports  (AL/HR-TP-1 995-0033  and  AL/HR-TP-1995-0034). 


CONCLUSIONS  AND  RECOMMENDATIONS 

The  IMIS  field  tests  and  demonstrations  proved  to  be  a  valuable  source  of  information 
regarding  the  IMIS  concept  and  implementation.  In  addition,  the  knowledge  gained  and 
experiences  provided  valuable  information  in  many  different  areas.  The  conclusions  and 
recommendation  of  the  field  tests  are  described  in  the  following  paragraphs. 

Conclusions 

The  Debrief  Test  showed  the  IMIS  debrief  process  to  be  much  more  efficient  compared  to 
the  current  method.  The  efficiency  was  due  to  the  smaller  number  of  CAMS  debriefing  screens 
accessed  and  due  to  the  IMIS/CAMS  interface.  This  was  especially  true  for  the  Code  1  debrief 
sessions  when  no  work  orders  were  opened.  In  addition,  the  amoimt  of  time  the  pilot  was 
involved  did  not  increase,  even  though  the  maintenance  debriefer  entered  the  information  into 
IMIS  with  the  pilot  present  (in  contrast  to  the  current  system,  where  the  debriefer  often  waits 
imtil  later  to  enter  the  information  into  CAMS). 

The  debriefers  also  preferred  the  IMIS  user  interface,  with  features  like  pre-filled  data 
fields  and  pull-down  menus.  The  debrief  enhanced  question  sets  also  provided  the  capability  for 
any  maintenance  debriefer,  regardless  of  experience  level  or  AFSC,  to  ask  technical  questions 
about  the  discrepant  system  and  enter  the  descriptive  discrepancy  information  based  on  the  pilot's 
observations. 

The  End-to-End  Demonstration  showed  IMIS  is  capable  of  providing  maintenance 
personnel  with  both  the  management  and  technical  information  they  require.  Both  the  quantity 
and  the  currency  of  information  exceed  the  data  currently  available  to  them.  IMIS  automatically 
interfaced  with  CAMS,  relieving  the  user  of  manually  entering  data  into  CAMS.  This  was  seen 
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as  a  great  advantage,  in  that  this  automatie  interface  could  save  time  and  provide  more  accurate 
information  for  all  maintenance  personnel  and  the  maintenance  information  management  system. 

The  ability  of  IMIS  to  automatically  create  and  record  accurate  maintenance  data  in  a 
single  system  (open  and  close  work  orders,  record  maintenance  actions,  and  send  the  MDC  data 
to  the  necessary  legacy  databases)  are  very  desirable  features.  Eliminating  the  unique  database 
interfaces  (single  data  entry  that  will  feed  the  data  to  multiple  databases),  having  all  the  needed 
technical  data  and  simplified  wiring  diagrams  on  the  PMA,  and  being  able  to  order  parts  from 
the  job  site  will  help  make  the  maintenance  personnel  be  more  efficient.  However,  system 
response  times  and  reliability  need  to  be  improved  in  order  to  enhance  the  user's  overall 
efficiency. 

A  seamless  interface  between  the  various  software  processes  must  be  developed.  The 
transition  from  IMIS  to  the  TO  Present  software  was  apparent  to  the  user  and  was  magnified  by 
the  differences  in  the  user  interface.  The  user  interface  must  be  made  consistent  throughout  the 
system. 


Recommendations 

Overall,  the  IMIS  system  performed  well  and  was  well-received  during  its  field  test  at 
Luke  AFB.  A  large  number  of  lessons  learned  and  recommendations  regarding  hardware, 
software,  system,  functionality,  human  factors,  data,  and  programmatics  are  included  in  Volume 
3  of  this  Final  Program  Report  and  have  been  incorporated  in  the  SSS.  The  key  hardware  and 
software  recommendations  are  summarized  in  the  following  paragraphs. 

The  bubble-dome-type  keys  used  on  the  PMA  keypad  made  it  difficult  to  tell  whether  the 
key  had  responded  to  a  key  press,  resulting  in  the  user  pressing  the  key  numerous  times.  The 
tactile  feedback  provided  by  the  keypad  did  not  guarantee  that  electrical  contact  had  been  made. 
Lowering  the  resistance  in  the  keypad,  thereby  reducing  the  force  required  to  press  the  PMA  key, 
could  also  enhance  key  activation. 

The  PMA  batteries  worked  well,  but  the  battery  replacement  was  inefficient.  There  was 
often  inadequate  time  between  the  receipt  of  a  low-power  message  and  the  occurrence  of  power 
failure;  this  may  require  a  different  type  of  battery,  since  this  is  typical  of  the  NiCad  batteries 
used.  The  captive  screws  which  held  the  cover  in  place  were  very  small,  and  the  cover  was  not 
hinged  or  otherwise  fastened  to  the  body  of  the  PMA,  making  battery  replacement  awkward. 
Some  non-volatile  memory,  which  would  allow  the  PMA  battery  to  be  changed  without  having 
to  shut  it  down  all  the  way,  would  also  be  desirable. 

Direct  sunlight  affected  the  readability  of  the  PMA  display,  which  would  become  darker 
and  eventually  unreadable.  The  adjustment  of  contrast  via  software  accessible  through  the  main 
menu  bar  is  not  adequate  if  screen  visibility  has  already  deteriorated  to  the  point  where  the  screen 
is  unreadable.  The  contrast  adjustment  should  be  on  the  PMA  box  itself  In  addition,  glare  and 
off-angle  visibility  need  to  be  improved.  Displays  considered  for  future  PMAs  should  imdergo 
thorough  evaluations  and  tradeoffs  considering  these  factors,  as  well  as  cost  and  power. 
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Wireless  communication  is  required  for  an  effective  maintenance  operational  environment. 
Without  the  wireless  communication,  flightline  managers  would  not  have  the  most  current 
information  available  to  perform  their  tasks.  The  entire  aircraft  maintenance  area  must  be 
supported  by  wireless  commimication.  RF  coverage  was  adequate  for  the  flightline  area  but  was 
inconsistent  in  the  hangars,  where  it  was  also  required.  Providing  large  area  coverage  may 
require  the  use  of  repeaters. 

The  system  was  saturated  by  the  RF  messages  sent  to  a  relatively  small  number  of  PMAs. 
To  support  messaging  in  an  unconstrained  environment  when  dealing  with  the  number  of  PMAs 
required  to  support  an  entire  FS,  a  mechanism  for  filtering  messages  may  be  required. 
Improving  the  efficiency  of  parsing  the  messages  into  the  database  would  also  help  alleviate  this 
problem. 

The  screen-based  CAMS  interface  was  inefficient  and  susceptible  to  frequent  interruptions 
due  to  minor  software  changes.  A  standard  legacy  database  interface,  which  could  require 
changes  to  both  CAMS  and  IMIS,  should  be  developed.  A  better  method  would  utilize 
Structured  Query  Language  (SQL).  In  addition,  detailed  information  regarding  updates  to 
CAMS  was  not  disseminated  to  the  organizations  which  needed  access  to  that  information.  Time 
and  effort  were  wasted  because  this  information  was  either  unavailable  or  incomplete.  The 
existence  of  a  CAMS  data  dictionary,  in  which  attributes  and  their  values  were  defined,  would 
have  been  of  immense  help. 

The  tools  selected  for  the  software  development  environment  were  insufficiently  mature  to 
support  the  functional  and  performance  requirements.  Throughout  software  development, 
various  bugs  and  limitations  were  encountered,  with  very  few  quick  fixes.  A  more  extensive 
analysis  of  the  available  tools  and  platforms  should  be  conducted  before  beginning 
implementation. 

Utilities  to  perform  certain  database  changes  (such  as  updating  the  list  of  aircraft  or 
personnel)  would  have  provided  a  much  faster  mechanism  for  updating  databases.  With  the 
current  software,  many  of  these  changes  could  only  be  done  by  building  a  new  database,  a 
process  which  takes  a  significant  number  of  hours  between  creation  and  testing. 

Aural  and  more  attention-getting  visual  alerts  regarding  incoming  messages  should  be 
available  on  both  the  PMA  and  the  MIW,  especially  for  time-critical  messages  for  certain  users 
like  expediters  or  the  production  superintendent.  The  display  of  the  message  icon  did  not 
provide  adequate  notice  to  the  user  that  a  message  had  been  received. 
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ACRONYMS 


ACC 

Air  Combat  Command 

AFB 

Air  Force  Base 

AFR 

Air  Force  Regulation 

AFSC 

Air  Force  Specialty  Code 

AIMS 

ATF  Integrated  Maintenance  System 

AIP 

Aircraft  Interface  Panel 

AL/HRG 

Armstrong  Laboratory  Logistics  Research  Division 

APG 

Airplane  General 

API 

Application  Programming  Interface 

ATF 

Advanced  Tactical  Fighter 

BIT 

Built-In  Test 

CA 

Control  Architecture 

CAMS 

Core  Automated  Maintenance  System 

CD  ROM 

Compact  Disk  Read-Only  Memory 

CDM 

Content  Data  Model 

CDRL 

Contract  Data  Requirements  List 

CLSA 

Computer  Logics  Synchronous  Adaptor 

CND 

Can  Not  Duplicate 

CPU 

Central  Processing  Unit 

CSA 

Computer  Systems  Architecture 

CSCI 

Computer  Software  Configuration  Item 

DC 

Direct  Current 

DCM 

Deputy  Commander  for  Maintenance 

DEMO 

Demonstration 

EDM 

External  Data  Management 

FCR 

Fire  Control  Radar 

FRM 

Fault  Reporting  Manual 

FS 

Fighter  Squadron 

GB 

Gigabyte 

HESAR 

Human  Engineering  System  Analysis  Report 

HUD 

Head-Up  Display 

I-Level 

Intermediate  Level 

lA 

Information  Architecture 

ICAM 

Integrated  Computer-Aided  Manufacturing 

IDD 

Interface  Design  Document 

IDEF 

ICAM  Definition 

IMIS 

Integrated  Maintenance  Information  System 

IMIS-DM 

IMIS  Diagnostics  Module 

IMISA 

IMIS  Architecture 

INS 

Inertial  Navigation  Set 

IRS 

Interface  Requirements  Specification 

LAN 

Local  Area  Network 

LFWC 

Lockheed  Fort  Worth  Corporation 
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LRU 

Line  Replaceable  Unit 

MASA 

Modular  Avionics  Systems  Architecture 

MB 

Megabyte 

MHz 

Megahertz 

MIW 

Maintenance  Information  Workstation 

MML 

Memory  Module  Loader 

MOC 

Maintenance  Operations  Center 

NASA 

National  Aeronautics  and  Space  Administration 

NiCad 

Nickel-Cadmium 

0-Level 

Organizational  Level 

OCD 

Operational  Concept  Document 

PIDS 

Prime  Item  Development  Specification 

PIPFS 

Prime  Item  Product  Fabrication  Specification 

PMA 

Portable  Maintenance  Aid 

R&D 

Research  and  Development 

RAM 

Random  Access  Memory 

RF 

Radio  Frequency 

RS 

Radio  Standard 

RTOK 

Retest  OK 

SBLC 

Standard  Base  Level  Computer 

SBSS 

Standard  Base  Supply  System 

SCO 

Santa  Cruz  Operation 

SCSI 

Small  Computer  System  Interface 

SDD 

Software  Design  Document 

SEA 

Systems  Engineering  Analysis 

SQL 

Structured  Query  Language 

SRS 

Software  Requirements  Specification 

SSC 

Standard  Systems  Center 

sss 

System/Segment  Specification 

TAC 

Tactical  Air  Command 

TLX 

Task  Load  Index 

TO 

Technical  Order 

TO  Present 

TO  Presentation 

UI 

User  Interface 

USAFE 

United  States  Air  Forces  -  Europe 

VGA 

Video  Graphics  Array 
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